home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / internet-drafts / draft-moore-smtp-drpt-00.txt < prev    next >
Text File  |  1993-09-17  |  22KB  |  548 lines
  1. Network Working Group                                        Keith Moore
  2. Internet Draft                                   University of Tennessee
  3.                                                        16 September 1993
  4.  
  5.  
  6.                          SMTP Service Extension
  7.                           for Delivery Reports
  8.  
  9.                       draft-moore-smtp-drpt-00.txt
  10.  
  11.  
  12. 1. Status of this Memo
  13.  
  14.    This document is an Internet Draft.  Internet Drafts are working
  15. documents of the Internet Engineering Task Force (IETF), its Areas, and
  16. its Working Groups.  Note that other groups may also distribute working
  17. documents as Internet Drafts.
  18.  
  19.    Internet Drafts are valid for a maximum of six months and may be
  20. updated, replaced, or obsoleted by other documents at any time.  (The
  21. file 1id-abstracts.txt, available via anonymous ftp from nic.ddn.mil,
  22. describes the current status of each Internet Draft.)  It is not
  23. appropriate to use Internet Drafts as reference material or to cite them
  24. other than as a "work in progress".
  25.  
  26.  
  27. 2. Abstract
  28.  
  29.    This memo defines an extension to the SMTP service whereby the an
  30. SMTP client may specify to an SMTP server the conditions under which a
  31. delivery report should be generated.
  32.  
  33.  
  34. 3. Introduction
  35.  
  36.    The SMTP protocol [1] requires that an SMTP server provide
  37. notification of delivery failure, if it determines that a message cannot
  38. be delivered to one or more recipients.  Traditionally, such
  39. notification consists of an ordinary Internet mail message (format
  40. defined by [2]), sent to the envelope sender address (the argument of
  41. the SMTP MAIL command), containing an explanation of the error and at
  42. least the headers the failed message.
  43.  
  44.    Experiences with large mail distribution lists [3] indicates that
  45. such messages are often insufficient to diagnose problems, or even to
  46. determine at which host or for which recipients a problem occurred.  In
  47. addition, the lack of a standardized format for delivery notifications
  48. in Internet mail makes it difficult to exchange such notifications with
  49. other message handling systems.
  50.  
  51.    This memo uses the mechanism defined in [4] to define an extension to
  52. the SMTP service, by which an SMTP client may request that an SMTP
  53. server issue or not issue a delivery status notification (DSN) under
  54. certain conditions.  The format of a DSN is defined in [5].
  55.  
  56.  
  57.  
  58. K. Moore                  Expires 16 March 1994                 [Page 1]
  59.  
  60.  
  61. Delivery Reports                                       16 September 1993
  62.  
  63.  
  64.  
  65. 4. Framework for the Delivery Report Extension
  66.  
  67.    The following service extension is therefore defined:
  68.  
  69. (1) The name of the SMTP service extension is "Delivery Report";
  70.  
  71. (2) the EHLO keyword value associated with this extension is "DRPT", the
  72.     meaning of which is defined in section 5 of this memo;
  73.  
  74. (3) no parameters are allowed with this EHLO keyword value;
  75.  
  76. (4) three optional parameters are added to the RCPT command, and one
  77.     optional parameter is added to the MAIL command:
  78.  
  79.     An optional parameter for the RCPT command, using the esmtp-keyword
  80.     "DRPT", (to request a delivery-report), is defined in section 6.1,
  81.  
  82.     An optional parameter for the RCPT command, using the esmtp-keyword
  83.     "NORET", (to specify that delivery reports not return the contents
  84.     of a message), is defined in section 6.2,
  85.  
  86.     An optional parameter for the RCPT command, using the keyword "TAG",
  87.     (used to communicate additional information for use by internetwork
  88.     mail gateways), is defined in section 6.3, and
  89.  
  90.     An optional parameter for the MAIL command, using the keyword
  91.     "MSGID", (used to propagate a unique identifier to be returned in a
  92.     delivery report), is defined in section 6.4;
  93.  
  94. (5) no additional SMTP verbs are defined by this extension.
  95.  
  96.    The remainder of this memo specifies how support for the extension
  97.     affects the behavior of a client and server SMTP.
  98.  
  99.  
  100. 5.  The Delivery Report service extension
  101.  
  102.    An SMTP client wishing to request a delivery report for a message may
  103. issue the EHLO command to start an SMTP session, to determine if the
  104. server supports any of several service extensions.  If the server
  105. responds with code 250 to the EHLO command, and the response includes
  106. the EHLO keyword DRPT, then the Delivery Report extension is supported.
  107.  
  108.    When any SMTP server returns a positive (2xx) reply code in response
  109. to a RCPT command, agrees to accept responsibility for either delivering
  110. the message to the named recipient, or sending a notification to the
  111. sender of the message indicating that delivery has failed.  By returning
  112. a DRPT keyword in response to an EHLO command, a server also agrees to
  113. generate a Delivery Status Notification (DSN) according to the
  114. parameters of each RCPT command, when it returns a positive response to
  115. the RCPT command.  (The client SMTP is responsible for generating the
  116.  
  117.  
  118.  
  119. K. Moore                  Expires 16 March 1994                 [Page 2]
  120.  
  121.  
  122. Delivery Reports                                       16 September 1993
  123.  
  124.  
  125.  
  126. necessary delivery reports if the server SMTP returns a failure reply
  127. code.)  Such DSNs must be in the format defined in [5].
  128.  
  129.    The additional parameters allow the sender (via the client SMTP) to
  130. specify that a delivery report should be issued:
  131.  
  132. (a) upon successful delivery or failure to deliver a message, or
  133. (b) only on failure to deliver a message, or
  134. (c) not at all.
  135.  
  136.    In addition, the sender may specify that the contents of a message
  137. are not to be returned in a delivery report.
  138.  
  139.  
  140. 6.  Additional parameters for RCPT and MAIL commands
  141.  
  142.    The extended RCPT and MAIL commands are issued by a client with it
  143. wishes to request a delivery report from the server, under certain
  144. conditions, for a particular recipient.  The extended RCPT and MAIL
  145. commands are identical to the RCPT and FROM commands defined in [1],
  146. except that one or more of the following parameters appear after the
  147. sender or recipient address, respectively.  The general syntax for
  148. extended SMTP commands is defined in [4].
  149.  
  150.  
  151. 6.1  The DRPT parameter of the ESMTP RCPT command
  152.  
  153.    The esmtp-keyword "DRPT" may be appear in the RCPT command to modify
  154. the default behavior of the MTA when generating delivery notifications
  155. for that recipient.  Acceptable esmtp-values for the DRPT parameter are
  156. the following:
  157.  
  158. ALWAYS    always generate a delivery report on delivery
  159. FAILURE   generate a delivery report on delivery failure only
  160. NEVER     do not generate a delivery report
  161.  
  162.    If no DRPT parameter appears, the server should generate a delivery
  163. report only upon failure to deliver a message.  This is the behavior
  164. specified by [1].  Ideally, servers should use the delivery report
  165. format defined in [5] to report delivery failures, even if they do not
  166. implement this SMTP extension.
  167.  
  168.    A DRPT esmtp-keyword with an esmtp-value of ALWAYS indicates that the
  169. server should accept responsibility for generating a DSN (in the correct
  170. format) upon any of the following conditions: (a) successful delivery to
  171. the indicated recipient's mailbox, (b) relaying or gatewaying of the
  172. message into a environment that cannot or will not accept responsibility
  173. for generating well-formatted DSNs, (c) forwarding of the message to a
  174. mailbox other than that specified by the sender, or (d) failure to
  175. deliver a message.
  176.  
  177.  
  178.  
  179.  
  180. K. Moore                  Expires 16 March 1994                 [Page 3]
  181.  
  182.  
  183. Delivery Reports                                       16 September 1993
  184.  
  185.  
  186.  
  187.    A DRPT esmtp-keyword with an esmtp-value of FAILURE indicates that
  188. the server should accept responsibility for generating a DSN when (a)
  189. relaying or gatewaying of the message into an environment that cannot or
  190. will not accept responsibility for generating well-formatted DSNs, or
  191. (b) forwarding of the message to a mailbox other than that specified by
  192. the sender, or (c) failure to deliver the message.
  193.  
  194.    A DRPT esmtp-keyword with an esmtp-value of NEVER indicates that the
  195. server should not generate a DSN under any conditions, and should accept
  196. responsibility for ensuring that no DSN is generated for this recipient.
  197. (If the message is further relayed via a SMTP server that does not
  198. support this extension, this may be accomplished by using an empty
  199. sender address in the MAIL command.  This may require a separate SMTP
  200. session if not all recipients have DRPT=NEVER.)
  201.  
  202.  
  203. 6.2 The NORET parameter of the ESMTP RCPT command
  204.  
  205.    The presense of the NORET esmtp-keyword on the extended RCPT command
  206. indicates that the message should not be included in any delivery
  207. notification issued for this recipient.  A missing NORET parameter
  208. indicates that a message should be returned in a delivery notification
  209. for this recipient.
  210.  
  211.  
  212. 6.3 The TAG parameter to the ESMTP RCPT command
  213.  
  214.    A TAG esmtp-keyword is used to convey additional per-recipient
  215. information for messages which originated in an non-SMTP environment,
  216. and for which a delivery report was requested by the sender.  The
  217. definition of the esmtp-value is not defined by this memo; the
  218. definition to be provided by the specifications for gatewaying delivery
  219. reports to and from non-SMTP environments.
  220.  
  221.  
  222. 6.4  The MGSID parameter to the ESMTP MAIL command
  223.  
  224.    The optional MSGID esmtp-keyword may appear in the MAIL SMTP command.
  225. The esmtp-value associated with this string is formatted according to
  226. the rules for "msg-id" in [2].  Note that this value is not necessarily
  227. the same as in the Message-ID header field of the message.
  228.  
  229.  
  230. 6.5  Server responses to these commands
  231.  
  232.    The presence of any of the DRPT, NORET, or TAG esmtp-keywords in a
  233. RCPT command, or the MSGID esmtp-keyword in a MAIL command, does not
  234. affect the server's response to that command (unless there is a syntax
  235. error in the command itself).  By issuing the DRPT keyword in response
  236. to the EHLO command, the server has indicated its willingness to accept
  237. these keywords and to process them according to the rules below.  A
  238.  
  239.  
  240.  
  241. K. Moore                  Expires 16 March 1994                 [Page 4]
  242.  
  243.  
  244. Delivery Reports                                       16 September 1993
  245.  
  246.  
  247.  
  248. server MAY NOT refuse the responsibility to issue delivery reports on a
  249. per-recipient basis.
  250.  
  251.  
  252. 7.  Format of delivery notifications
  253.  
  254.    The format of delivery status notifications is defined in [5].
  255. Delivery status notifications are to be returned to the sender of the
  256. original message according as outlined below.
  257.  
  258.  
  259. 7.1 SMTP Envelope to be used with delivery status notifications
  260.  
  261.    The sender address (in the SMTP MAIL command) must be an empty
  262. string.  The recipient address (in the RCPT command) is copied from the
  263. MAIL command of the message for which a delivery notification is being
  264. issued.  The envelope of a delivery notification may not use the DRPT
  265. option.
  266.  
  267.  
  268. 7.2 Message/delivery-report Content-Type Header Parameters
  269.  
  270.    The parameters of the message/delivery-report content type are
  271. derived as follows:
  272.  
  273.    The "id" parameter of the delivery-report contains the envelope
  274. message-id as provided with the MSGID esmtp-keyword of the MAIL command
  275. of the message for which a report is being generated.
  276.  
  277.    Unless the sender requested that the message not be returned in a
  278. delivery report, a unique content-id is generated by the reporting MTA,
  279. and the "returned-content" parameter of the message/delivery-report
  280. content-type header is used to indicate the content-id of that body
  281. part.
  282.  
  283.    *** NOTE IN DRAFT: It might be that delivery reports should include
  284. the *headers* of a failed message, even if the sender requested that the
  285. message not be returned. ***
  286.  
  287.    If the text of any of the "text" body fields requires a character set
  288. other than ASCII, the "charset" parameter should be used to indicate
  289. that character set.  Only one "alternate" character set may be used per
  290. delivery notification.  (This feature will not be used if the "text" is
  291. copied from SMTP responses, since SMTP responses must be entirely in
  292. ASCII.)
  293.  
  294.  
  295. 7.3 Message/delivery-report body field parameters
  296.  
  297.    The body of the message/delivery-report body part contains a STIF [6]
  298. record for each recipient.  The fields of this per-recipient record are
  299.  
  300.  
  301.  
  302. K. Moore                  Expires 16 March 1994                 [Page 5]
  303.  
  304.  
  305. Delivery Reports                                       16 September 1993
  306.  
  307.  
  308.  
  309. derived as described below.  These instructions apply to the generation
  310. of delivery reports by an ESMTP client that supports this specification,
  311. in response to SMTP or ESMTP transactions with a server.  If an ESMTP
  312. client uses some other protocol to deliver or relay a message, some of
  313. the per-recipient fields are not required.
  314.  
  315.    Refer to [5] for the syntax of each field.
  316.  
  317. orig-rcpt contains the recipient address from the RCPT command.  (Since
  318.           this specification guarantees that the recipient address is
  319.           the same as specified by the sender, the "rcpt" field should
  320.           not be used.)
  321.  
  322. mta       contains the Internet domain name of the SMTP that provided
  323.           the information from which this report is derived.  This will
  324.           normally be the same as provided in the server's initial
  325.           greeting and the first line of the response to the EHLO
  326.           command.
  327.  
  328. date      contains the date at which the last delivery attempt occurred.
  329.  
  330. action    describes the action taken by the SMTP client generating the
  331.           report, as defined in section 8.
  332.  
  333. status    If available, the reply-code returned by the "remote" SMTP
  334.           server that informed "this" SMTP client (the one issuing the
  335.           report) of the condition that caused the client to generate
  336.           the report for this recipient.  (This field is not required if
  337.           the MTA generating the report used some protocol other than
  338.           SMTP to deliver or relay the message.)
  339.  
  340. text      Either the text supplied by the "remote" SMTP along with the
  341.           reply-code in "status", or any appropriate explanatory text.
  342.  
  343. tag       The esmtp-value supplied with the TAG esmtp-keyword of the
  344.           RCPT command for this recipient, if present.
  345.  
  346. 7.4 Returned message body part
  347.  
  348.    Unless the sender of the original message requested that the original
  349. message not be included in a delivery report, the third body part of a
  350. message/delivery-status-notification content should be the returned
  351. message, or some portion (e.g. the headers) thereof.
  352.  
  353.    The content-id of the returned message body part should be identical
  354. to that provided in the returned-content parameter of the
  355. message/delivery-report body part for this delivery notification.
  356.  
  357.  
  358. 8.  Conformance requirements
  359.  
  360.  
  361.  
  362.  
  363. K. Moore                  Expires 16 March 1994                 [Page 6]
  364.  
  365.  
  366. Delivery Reports                                       16 September 1993
  367.  
  368.  
  369.  
  370.    An SMTP server which claims compliance with this specification MUST
  371. implement the EHLO command as described in [4], and return the DRPT
  372. keyword in response to the EHLO command.  In addition, it MUST accept
  373. the DRPT, NORET, and TAG parameters of the RCPT command and the MSGID
  374. parameter of the MAIL command.
  375.  
  376.    When an SMTP server accepts responsibility for delivery of a message
  377. to a recipient whose RCPT command contains a DRPT or NORET keyword (by
  378. returning a 2xx reply code in response to that command), it also agrees,
  379. for each recipient, to either:
  380.  
  381. (a) transfer responsibility for the generation of a delivery
  382.     notification for that recipient, to another ESMTP server that
  383.     implements this extension, or
  384. (b) transfer responsibility for the generation of such a notification to
  385.     a gateway into a "foreign" (non-SMTP-based) electronic mail
  386.     environment, which provides a similar delivery notification
  387.     facility, arranges for such notifications to be returned to the
  388.     sender of the message, via a gateway that will translate the foreign
  389.     delivery notifications into the format defined in [5].
  390. (c) successfuly deliver the message to the mailbox named by the original
  391.     sender of the message, or
  392. (d) generate a delivery status notification in accordance with this
  393.     specification.
  394.  
  395.  
  396. 8.1 Transfer of delivery-report information via SMTP
  397.  
  398.    If an SMTP client relays a message to an SMTP server which advertises
  399. the DRPT keyword in response to the client's EHLO command, the client
  400. must issue a MSGID parameter to the MAIL command (if a MSGID parameter
  401. was supplied by client's predecessor), and likewise copy the DRPT, RET,
  402. and TAG esmtp-keywords and values along with each RCPT command relayed
  403. to the server.
  404.  
  405.    The server accepts responsibility for generating any requested
  406. delivery reports for each recipient for which it returns a positive
  407. (2xx) reply code in response to the RCPT command.  For any failed
  408. recipients, the client must generate a delivery report with an "action"
  409. value of "failed", and an "mta" value equal to Internet domain name of
  410. the server SMTP.
  411.  
  412.    If an SMTP client relays a message to an SMTP server which does not
  413. advertise the DRPT keyword in response to the EHLO command, the client
  414. must generate a delivery report for each recipient for whom a delivery
  415. report is required.  For any failed recipients, the client will generate
  416. a delivery report with an "action" value of "failed".  For any other
  417. recipients, the client will generate a delivery report with an "action"
  418. value of "relayed".  In either case, the "mta" value is set to the
  419. Internet domain name of the server SMTP.  If DRPT=NEVER for any
  420. recipients, the client SMTP should relay the message to those
  421.  
  422.  
  423.  
  424. K. Moore                  Expires 16 March 1994                 [Page 7]
  425.  
  426.  
  427. Delivery Reports                                       16 September 1993
  428.  
  429.  
  430.  
  431. recipients, (using a separate SMTP session if necessary), with an empty
  432. sender address in the MAIL command.
  433.  
  434.  
  435. 8.2 Gatewaying into a foreign environment
  436.  
  437.    If an SMTP server gateways the message into a foreign electronic mail
  438. system which supports similar delivery notifications, and can arrange
  439. for all notifications issued from within that mail system to be returned
  440. via a suitable gateway such that the foreign delivery notifications will
  441. be translated into the format defined in [5], then it need issue
  442. delivery reports only for those recipients for which the foreign mail
  443. system would not agree to deliver the message.
  444.  
  445.    The foreign mail system need not support exactly the same semantics
  446. for delivery notification that are described here.  In particular, the
  447. foreign mail system may not be able to honor the sender's request that
  448. the message be or not be returned along with a delivery report; and the
  449. foreign mail system need not issue reports when mail is forwarded within
  450. that environment.  (In the latter case the gateway should use the "rcpt"
  451. field when translating a delivery report from that environment, rather
  452. than the "orig-rcpt" field.)
  453.  
  454.    If appropriate delivery notifications from the foreign environment
  455. cannot be provided, the SMTP server must issue a delivery report for
  456. each recipient, containing an "action" value of "relayed", and an "mta"
  457. value equal to the Internet domain of the SMTP server.
  458.  
  459.  
  460. 8.3 Delivery, forwarding, list expansion
  461.  
  462.    Upon final delivery to the recipient's mailbox, as named by the
  463. sender), an SMTP must issue any requested delivery reports with an
  464. "action" value of "delivered" and an "mta" value equal to the Internet
  465. domain of the SMTP server.  (Note that this is not necessarily the same
  466. as the domain part of the recipient address).  If the delivery fails,
  467. the "action" value should instead be "failed.
  468.  
  469.    When a message is "forwarded" to another recipient address than that
  470. specified by the sender, the SMTP which performs the forwarding must
  471. issue a delivery report for that recipient (unless DRPT=NEVER), with an
  472. "action" value of "forwarded" and an "mta" value equal to the Internet
  473. domain of the server performing the forwarding.
  474.  
  475.    *** NOTE IN DRAFT: we should use the TAG facility here to allow
  476. propagation of delivery reports across mail forwarding boundaries.  It
  477. would be a shame to allow delivery reports to cross inter-MTS boundaries
  478. and not to cross mail forwarding boundaries within RFC 822!  ***
  479.  
  480.    Successful delivery of a message to an address associated with a mail
  481. distribution list cases a delivery report to be generated with an
  482.  
  483.  
  484.  
  485. K. Moore                  Expires 16 March 1994                 [Page 8]
  486.  
  487.  
  488. Delivery Reports                                       16 September 1993
  489.  
  490.  
  491.  
  492. "action" value of "delivered".  Delivery report requests are NOT to be
  493. propagated to the members of the distribution list.
  494.  
  495.  
  496. 9. References
  497.  
  498. [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
  499.     USC/Information Sciences Institute, August 1982.
  500.  
  501. [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  502.     Messages", STD 11, RFC 822, UDEL, August 1982.
  503.  
  504. [3] Westine, A., Postel, J. "Problems with the Maintenance of Large
  505.     Mailing Lists.", RFC 1211, USC/Information Sciences Institute, March
  506.     1991.
  507.  
  508. [4] Klensin, J., Freed, N., Rose, M., Stefferud, E., Crocker., D.  "SMTP
  509.     Service Extensions", RFC 1425, United Nations University, Innosoft
  510.     International, Inc., Dover Beach Consulting, Inc., Network
  511.     Management Associates, Inc., The Branch Office, February 1993.
  512.  
  513. [5] Moore, K.  "MIME Content-Types For Delivery Status Notifications",
  514.     Internet-Draft "draft-moore-mime-delivery-00.txt", 16 September
  515.     1993.
  516.  
  517. [6] Crocker, D.  "Structured Text Information Format (STIF)", Internet-
  518.     Draft "draft-crocker-stif-00.txt", June 1993.
  519.  
  520.  
  521. 10. Author's address
  522.  
  523. Keith Moore
  524. University of Tennessee
  525. 107 Ayres Hall
  526. Knoxville, TN 37996-1301
  527. USA
  528.  
  529. email: moore@cs.utk.edu
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546. K. Moore                  Expires 16 March 1994                 [Page 9]
  547.  
  548.